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Abstract 

Scaling data storage is a significant concern in enter- 
prise systems and Storage Area Networks (SANs) are de- 
ployed as a means to scale enterprise storage. SANs based 
on Fibre Channel have been used extensively in the last 
decade while iSCSI is fast becoming a serious contender 
due to its reduced costs and unified infrastructure. This 
work examines the performance ofiSCSI with multiple TCP 
connections. Multiple TCP connections are often used to 
realize higher bandwidth but there may be no fairness in 
how bandwidth is distributed. We propose a mechanism 
to share congestion information across multiple flows in 
"Fair-TCP" for improved performance. Our results show 
that Fair-TCP significantly improves the performance for 
I/O intensive workloads. 



1. Introduction 

Future computer systems are required to scale to large 
volume of data that is being generated and used, with in- 
creasing capacities and dropping prices of magnetic disks. 
Traditional DAS based architectures, based on parallel 
SCSI transport, scale poorly owing to their distance, con- 
nectivity and throughput limitations and are being replaced 
by networked storage systems like SAN. Figure Q] shows a 
SAN connecting multiple servers to multiple targets. 

SANs, where the storage devices are connected directly 
to a highspeed network, can provide high scalability and 
throughput guarantees; SANs allow any-to-anywhere ac- 
cess across the network, using interconnect elements such 
as routers, gateways, hubs and switches; they also facilitate 
storage sharing between possibly heterogeneous servers to 
improve storage utilization and reduce downtime. 

Entities in a SAN, both storage and servers, communi- 
cate using SCSI commands. A sender encapsulates SCSI 




Figure 1. Elements and Ecosystem of an en- 
terprise SAN 

commands over a transport protocol and sends it to one or 
more receivers; receivers receive the payload, decapsulates 
the commands, and execute them. Thus a SAN is defined 
by the transport it uses and the encapsulation standard it 
follows. In this lieu, there are two competing industry stan- 
dards - FC and iSCSI, which allow us to build SANs, each 
based on differing transport and encapsulation standards. 

The Fibre Channel (FC) is a serial interface, usually im- 
plemented with fibre-optic cable. FC Standard [2| cov- 
ers the physical, link, network and transport layers of the 
OSI network stack and also provide a SCSI encapsulation 
protocol - FCP. FC SANs, with most FCP implementa- 
tions being hardware accelerated, provide better through- 
put guarantees. However, FC installations are costlier and 
are cannot be deployed over long distances. Fibre Chan- 
nel requires custom network components and is not able to 
take advantage of the steep technology curves and dropping 
costs of IP-based networks. 

Internet SCSI or iSCSI 0] is a storage networking stan- 
dard that transports SCSI commands over TCP/IP, essen- 
tially tunneling storage protocols on top of TCP, hence IP, 
to leverage the installed equipment base. This allows iSCSI 
to be used over any TCP/IP network infrastructure with the 
remote device being seen by the operating system as a lo- 
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cally available block-level device. Unlike Fibre Channel, 
iSCSI can run on any network infrastructure that supports 
TCP/IP. A network that uses iSCSI needs only one network 
for both storage and data traffic whereas Fibre Channel re- 
quires separate infrastructure for storage and data traffic. 
However, a response to a block-level request in iSCSI may 
encounter a greater delay compared to Fibre Channel, de- 
pending on the network conditions and the location of the 
target. 

Current efforts to improve end-to-end performance for 
TCP are taking advantage of the empirically discovered 
mechanism of striping data transfers across a set of paral- 
lel TCP connections between a sender and receiver to sub- 
stantially increase TCP throughput. However, when multi- 
ple connections are used between the same source-target 
pairs, the connections themselves interact/compete with 
each other in non trivial ways. In order to achieve optimal 
throughput it is imperative that we understand these inter- 
actions and treat the connections accordingly; failing which 
could lead to increased congestion and reduced throughput. 

In our work, we study the effects of using multiple TCP 
connections on iSCSI. It was shown in [ 10 1 that the aggre- 
gate iSCSI throughput increases with the increase in num- 
ber of TCP connections in an emulated wide area network. 
We find that the multiple TCP connections used by iSCSI 
compete with each other and result in lesser throughput 
for iSCSI than they are capable of. We propose a solu- 
tion named Fair-TCP based on TCP control block interde- 
pendence [20 1 for managing TCP connections. We com- 
pare the performance of our variant with the standard TCP 
Reno[3| with SACK[4|, using various workloads and vary- 
ing delays in an emulated wide area network. We find that 
for I/O intensive workloads such as sequential write to a 
large file, Postmark and Bonnie, Fair-TCP provides signif- 



icant performance improvements over standard TCP-Reno 
with SACK. 

Section 2 describes the behaviour of multiple TCP con- 
nections and its effects on iSCSI. The proposed solution 
is also outlined there. Section 3 details the experimental 
setup, tools and benchmarks used in our experiments. Sec- 
tion 4 presents our results with a discussion. Section 5 re- 
views related work. Section 6 concludes the paper. 

2. iSCSI and TCP 



SCSI standard assumes that the underlying transport is 
reliable and supports FIFO ordering of commands. TCP 
has mechanisms to acknowledge the received TCP packets 
and to resend/request packets that are not acknowledged 
within a certain time period, effectively guaranteeing reli- 
able and in-order delivery of packets. Choosing TCP as a 
transport is thus a natural choice. If iSCSI were defined on 
top of a protocol that is not reliable and in-order then iSCSI 
would have had to provide these services by itself. 

iSCSI initiators are usually connected to iSCSI targets 
using multiple TCP connections. The reason is two fold: 
due to TCP window size restrictions and round trip times 
over long distances, it might not be possible for a single 
TCP connection to utilize the full bandwidth capacity of 
the underlying link; secondly, there may also be several 
physical interconnects connecting the initiator and target, 
and it would be most desirable to aggregate and simulta- 
neously utilize all such existing physical interconnects. As 
TCP does not support such aggregation, an iSCSI session 
is therefore defined to be a collection of one or more TCP 
connections between the initiator and the target. 
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Figure 4. Fair-TCP Design 
2.1. Behaviour of multiple TCP connections 

Many applications use multiple TCP connections be- 
tween client and server for increased throughput. However 
these TCP connections are treated independently: most 
TCP implementations keep state on a per-connection ba- 
sis in a structure called TCP control block (TCB) or an 
equivalent construct and each of these TCP connections 
are handled independently. Several researchers (| 18], 1 19 1, 
ll20lD have shown that concurrent connections such as these 
compete with each other for link bandwidth, often resulting 
in unfair and arbitrary sharing of bandwidth. Concurrent 
connections do not share indications of congestion along 
the shared path between the sender and receiver. There- 
fore each connection independently pushes the network to 
a point where packet losses are bound to happen. Once 
the network is congested, all the competing connections re- 
duce their transmission windows drastically, thus limiting 
the effective bandwidth available to the application, This 
results in under utilization of the shared link, and hence 
less aggregate throughput than the application is capable 
of achieving. Also, it often happens that some of the con- 
nections stall due to multiple losses, while others proceed 
unaffected. Thus concurrent TCP connections, when left 
without any explicit arbitration, provide neither bandwidth 
utilization nor fairness. 

Some of the information in a TCB, like round-trip time 
(RTT), is not application specific but is specific to a host 
(or subnet). If there are multiple TCP connections between 
the same hosts, each will independently monitor its trans- 
missions to estimate the RTT between the hosts. Such a 
scheme is wasteful as it needs extra processing and mem- 
ory at a TCP endpoint. An alternate scheme is to share this 
information between such concurrent connections. 

In order to see if iSCSI suffers from any of the above 
problems, we evaluated the performance of iSCSI with 
multiple TCP connections. We observed traces of conges- 
tion window of each connection, for a sequential file write 
of 1GByte to see if the connections are competing with 
each other. Figure[3]shows a sample of traces of congestion 
window for 2 different connections in a WAN environment 
with delay of 4ms for a period of 1.2 seconds. The con- 
gestion window was collected approximately every 10ms. 



Ensemble Allocation 

conn_srtt = ecb_srtt 
conn_rttvar = ecb_rttvar 
conn_snd_cwnd = ecb_snd_cwnd/ref_cnt 
conn_snd_ssthresh = ecb_snd_ssthresh/ref_cnt 



Table 1. Ensemble Allocation 

Figure [2] shows a sample of the difference in congestion 
window of the 2 connections for a period of 50 seconds. 

From the traces, we can see the two connections com- 
pete for bandwidth resulting in one connection using the 
network more than the other. The observed mean and 
standard deviation for congestion window of the two con- 
nections are 3.38/2.14 and 3.38/2.13. The observed mean 
and standard deviation for the difference in window sizes 
shown in figure[2]is and 3.06. The mean in the window 
difference indicates that over long periods each connection 
gets the same amount of network bandwidth. The larger de- 
viation in window difference compared to the deviations in 
each connection's window, indicates that when one connec- 
tion has a large window the other connection has a smaller 
window. This is a very undesirable behaviour from the TCP 
connections which results in reduced throughput. Similar 
patterns were observed in all traces. For the above traces 
the mean turnaround time was 453 ms with a standard de- 
viation of 325ms which we try to reduce. Thus we un- 
derstand that the multiple connections between iSCSI do 
compete and share the bandwidth disproportionately and 
underutilized the resources. In our work, we share the con- 
gestion information among the different TCP connections 
to reduce the command turnaround times and increase the 
throughput of iSCSI. 

2.2. Fair-TCP 

Several researchers have worked on sharing the conges- 
tion information among multiple TCP connections (|20|, 
[21|, [22]). Touch |20| proposed sharing TCP state among 
similar connections to improve the behaviour of a connec- 
tion bundle. A bundle of TCP connections sharing TCB 
information is called an ensemble. We have implemented 
a congestion information sharing mechanism, Fair-TCP 
based on Touch|20|. The TCBs of individual connections 
are stripped of RTT and congestion control variables. In- 
stead, they now simply contain a reference to the Ensem- 
ble Control Block (ECB), of the ensemble they are part of. 
Fair- TCP does not support caching of TCB states, since 
connections in an iSCSI session are persistent for a very 
long time, and are not reestablished frequently. Figure [4] 
outlines the design of Fair-TCP. 

Fair-TCP aggregates congestion window and slow start 
threshold values in the ECB per ensemble. Ensemble allo- 
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cates fair share of available window to each connection. 
Fair-TCP shares the round trip time information among 
connections of the ensemble. Fair-TCP maintains a refer- 
ence count of the number of connections in the ensemble. 
Table[T]outlines the allocation of congestion information to 
connections of the ensemble. 

For each window update received from a connection, 
the aggregate window is adjusted appropriately. The most 
recent value of srtt (smoothed round trip time) and rttvar 
(round trip time variance) reported by a connection is main- 
tained in the ensemble. Whenever a new connection is es- 
tablished, it is added to the corresponding ensemble with- 
out any changes to the ensemble. If there is no ensemble 
corresponding to that connection, a new ensemble will be 
created and initialized with the values from that connection. 
Fair-TCP has been implemented on both the target and the 
initiator. 

3. Experimental Setup 
3.1. Tools and Benchmarks 

The UNH-iSCSI [ 15 ] protocol implementation of initia- 
tor and target is used for all our experiments. It is designed 
and maintained by UNH Interoperability lab's iSCSI Con- 
sortium. The implementation consists of initiator and target 
drivers for Linux 2.4.x and 2.6.x kernels. It supports mul- 
tiple sessions between a given initiator target pair, multiple 
connections per session, arbitrary number of outstanding 
R2Ts, all combinations of initialR2T and ImmediateData 
keys, arbitrary values of data transfer size related iSCSI pa- 
rameters and Error Recovery level 1 . 

The NIST Net (24l network emulation tool for 
GNU/Linux is used for introducing delays. NIST Net al- 
lows a GNU/Linux PC set up as a router to emulate a wide 
variety of network conditions. The tool is designed to al- 
low controlled, reproducible experiments for network per- 
formance sensitive/adaptive applications and control pro- 
tocols in a simple laboratory setting. By operating at the 
IP level, NIST Net can emulate the critical end-to-end per- 
formance characteristics imposed by various wide area net- 
work situations (e.g., congestion loss) or by various under- 
lying subnetwork technologies. The tool allows an inex- 
pensive PC-based router to emulate numerous complex per- 
formance scenarios, including: tunable packet delay distri- 
butions, congestion and background loss, bandwidth limi- 
tation, and packet reordering/duplication. 

Bonnie ++ [25| is a benchmark suite that is aimed at per- 
forming a number of simple tests of hard drive and file 
system performance. The benchmark tests database type 
access to a single file (or a set of files), and it tests cre- 
ation, reading, and deleting of small files which can simu- 
late the usage of programs such as Squid, INN, or Maildir 
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Figure 5. Experimental Testbed 

format email. The first six tests include per-char write, 
block write, block rewrite, per-char read, block read and 
random seeks. For each test, Bonnie reports the num- 
ber of Kilo-bytes processed per elapsed second, and the 
%cpu usage (sum of user and system). The next 6 tests 
involve file create/stat/unlink to simulate some operations 
that are common bottlenecks on large Squid and INN 
servers, and machines with tens of thousands of mail files 
in /var/spool/mail. 

The Postmark [26 1 benchmark models the workload 
seen by a busy web server and is sensitive to I/O latency. 
The workload is meant to simulate a combination of elec- 
tronic mail, netnews and web-based commerce transac- 
tions. Postmark creates a large number of small files that 
are constantly updated. Once the pool of files has been cre- 
ated, a specified number of transactions occur. Each trans- 
action consists of a pair of smaller transactions, i.e. Create 
file or Delete file and Read file or Append file. Each trans- 
action type and files it affects are chosen randomly. On 
completion of each run a report is generated showing met- 
rics such as elapsed time, transaction rate, total number of 
files created, read size, read throughput, write size, write 
throughput and so on. The Postmark configuration used in 
our experiments is listed in Tableland rest of the parame- 
ters have been set to default. 

3.2. Experimental Testbed 

Our experimental WAN emulation testbed is illustrated 
in Figure[5] Three machines were used in our experimental 
setup: initiator, router and target. All the three machines 
were connected to a D-Link DGS10008TL gigabit switch 
using gigabit NICs. 

The initiator hosted a 2.6 GHz Intel Pentium 4 proces- 
sor, 256 MBytes of RAM and Broadcom BCM5700 gigabit 
Ethernet controller. It was running the Linux 2.4.20 ker- 
nel. The system in which the target was hosted had a dual 
866 MHz Pentium III processor, 756 MBytes RAM and Fi- 
bre Channel host bus adapter. The target was connected to 
two JBODs, each housing three Seagate ST336752FC 15K 
RPM disks. The target was running a Linux 2.6.5 kernel 
for i686. The machine designated as router hosted a hyper- 
threaded 2.6 GHz Pentium 4 processor, 1 GB of RAM and 
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Table 2. Aggregate Congestion Window 



Figure 6. TCP Retransmits for block size of 
1024 bytes 

two gigabit NICs (D-Link DL2K and Intel 82547EI). 

Both the initiator and the target were running UNH 
iSCSI implementation. The machine designated as router 
between the initiator was running NIST Net network em- 
ulation tool to simulate a WAN environment. The WAN 
simulation was tuned in accordance with profiling informa- 
tion presented in Vern Paxson ll23l . which found that over 
long periods network connections suffered a 2.7% packet 
loss in a wide-area network. Performance measurements 
were calculated using varying delays. Socket buffer sizes 
on both the initiator and the target were set to 512KBytes. 

4. Results and Discussion 

In all our experiments 4 TCP connections were used in 
a session between the initiator and the target. Girish[10| 
identifies that beyond 4 connections the incremental in- 
crease in throughput is very low. Standard ethernet frame 
size of 1500 bytes was used in all experiments. We did 
not consider using jumbo frames, since in real systems not 
all components in the network path support jumbo frames. 
Large socket buffers are necessary to achieve peak perfor- 
mance for networks with large bandwidth-delay products. 
Socket buffers on both the initiator and the target were set 
to maximum value of 512KBytes. 

4.1. Sequential File Writes 

Figure [7] shows the performance of iSCSI for a sequen- 
tial file write of 1GB with different block sizes for write 
system call and varying network delays. A request for fsync 
was made before closing the file to ensure that all the data 
were written to the disk. Figure [7] shows the performance 
of iSCSI with standard Reno TCP with SACK (referred to 
as standard TCP or TCP) and Fair- TCP implemented on 
top of it. As shown in the figure Fair-TCP performs bet- 
ter than normal TCP-Reno at all delays. But as the delays 
increase the gap narrows, this we believe is due to delays 



overwhelming the window management efficiency of Fair- 
TCP. 

The block sizes used in the write system call had little 
effect on the overall throughput. To find out the reason be- 
hind such behaviour, we observed the SCSI request sizes 
received by iSCSI. Since the writes were sequential the op- 
erating system was able to bundle all the file writes into 
chunks of 128KBytes. The operating system aggressively 
caches each write and bundles them and sends to the disk. 
So the block size was not really a factor that affects the 
throughput for sequential file writes. 

With increasing delays throughput of iSCSI decreased 
rapidly. This we believe is mainly due to the synchronous 
nature of iSCSI. There can only be a limited number of 
pending SCSI requests that can be held with the target. The 
initiator has to wait for a minimum of an RTT seconds be- 
fore sending another request, i.e. the initiator can only send 
a limited number of SCSI requests during an RTT inter- 
val, which do not generate enough traffic in the network to 
match the bandwidth-delay product and get the maximum 
possible throughput. 

To see if the increase in throughput observed in Fair- 
TCP is due to better management of window or aggressive 
nature of Fair- TCP, we measured the number of TCP re- 
transmits for a block size of 1024 bytes with varying de- 
lays. The results are shown in figure [6] The number of 
retransmits for Fair-TCP are less than that of standard TCP 
in almost all the cases. Fair- TCP shares the most recent es- 
timate of RTT, between all connections. As a result it has 
fewer false retransmits than standard TCP. 

Table|3]shows the mean and Standard Deviation of SCSI 
command turnaround times in milliseconds (ms). Mean 
command turnaround times for Fair- TCP are less than that 
of standard TCP. The deviation percentage is also less for 
Fair- TCP than standard TCP except for the delay of 0ms, 
for which the deviation was more. Further experiments are 
required to determine the exact reason for such a behaviour. 

Table [2] shows the 1.5aggregate congestion window of 
all connections for TCP and Fair-TCP for different delays 
collected on the initiator (write traffic is mainly data-outs 
from the initiator). Fair-TCP has a larger window and has 
lesser deviation than standard TCP, which indicates Fair- 
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Figure 7. Throughput for Sequential File writes with varying delays and block sizes 



TCP has more stable window than standard TCP. 

In our experiments of sequential file writes, we observe 
that Fair-TCP offers better throughput and reduces the de- 
viation in command turnaround times. Fair- TCP is less 
burstier than standard TCP and reduces the number of false 
retransmits. Fair- TCP ensures that each connections an 
equal share of the available bandwidth. 

4.2. Sequential File Reads 

Figure [8] shows the performance of iSCSI with different 
block sizes for read system call and varying network de- 
lays. The displayed throughput are for a file read of 1GB. 
The throughput for reads are less than for writes. This is 
mainly due to buffer cache in the Linux kernel, which per- 
forms all the writes in the memory and flushes them to the 
disk as the memory becomes full. Whereas for reads, the 
operating system fetches the data from the disk whenever 
needed. 

As shown in the figure [8] Fair-TCP performs better than 
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Table 3. SCSI Command turnaround times for 
Writes 



normal TCP-Reno at all delays. However the increase in 
throughput is not significant. This is due to only one pend- 
ing read request at the SCSI layer. 

The block sizes used in read system call had little effect 
on the overall throughput. From the traces, we observed 
that the read request sent by the operating system are for 
128KBytes. The Linux kernel prefetches disk blocks start- 
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Figure 8. Throughput for Sequential file reads with varying block sizes and delays 
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liseconds (ms). Mean command turnaround times for Fair- 
TCP are less than that of standard TCP. The deviation per- Table 4. SCSI Command turnaround times for 
centages are also smaller for Fair-TCP. Reads 



4.3. Bonnie++ 

Table [5] shows the performance of Fair-TCP and Stan- 
dard TCP for Rewrites and Seeks with Bonnie++ [ 25 1 . Bon- 
nie+-i- was run in fast mode in all our experiments. File 
size of 1GB and block size of 1024 bytes were used. Re- 
sults for block writes and block reads are omitted, since 
single process Bonnie++ writes and reads are similar to the 



sequential file writes and reads which were discussed be- 
fore. Create/stat/unlink tests of bonnie++ were not used, 
since they were similar to workload generated by Postmark. 
Fair- TCP improves the performance of rewrites by about 
5-35%. Rewrites are similar to reads, except that they are 
dirtied and written back. The lower throughput seen for 
rewrites is mainly due to blocking during read requests. 
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Figure 9. Kernel components involved in a 
read operation 
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Table 5. Bonnie++ single process 

Fair-TCP improves the performance of seeks by 10-40%. 
Due to parallel seeks (3 seeks by default), more data is 
queued at the SCSI layer and results in better seek rate for 
Fair-TCP. 

Bonnie++ allows running several instances of it in a syn- 
chronized way using semaphores. All the process use the 
semaphore will start each test at the same time. We ran 
4 process of Bonnie++ using the above functionality pro- 
vided by semaphores. Each process performs the tests with 
a file size of 256MB and a block size of 1024 bytes. Results 
for block writes, block rewrites, block reads and random 
seeks are shown in figure [10] As observed in the previous 
experiments, Fair-TCP performs well but the improvement 
diminishes with increasing delays. However, for random 




Block Rewrites 




Random Seeks 



Figure 10. Bonnie++ 4 process 

seeks, Fair-TCP performs consistently better than standard 
TCP and improves the seek rate by 20-30% irrespective of 
delays. 



Parameter 


Value 


Number of Simultaneous Files 


20000 


Lower Bound on file size 


500 Bytes 


Upper Bound on file size 


100 KBytes 


Number of Transactions 


50000 



Table 6. Postmark Parameters 



4.4. Postmark 

Postmark(26) was run with 20000 initial files and 50000 
transactions. Figure QT| shows the times taken to run the 
postmark for standard TCP and Fair-TCP. Around 4GB 
of data was transacted during the execution of postmark. 
We notice that standard TCP needs 10-18% more time 
than Fair- TCP to run Postmark. Considering that Post- 
mark is single threaded and reads are synchronous, the 
performance improvement observed is mainly due to asyn- 
chronous file writes and metadata writes from the buffer 
cache. 

Figure [13] shows the read and write throughput for stan- 
dard TCP and Fair-TCP. The read and write throughput 
improves by about 10-18% for Fair- TCP. Due to filesys- 
tem caching effects and asynchronous nature of writes, 
throughput for writes in all cases is better than read 
throughput, and decreases with increasing delays. 

Postmark is completely single-threaded. In a normal 
web server, there would generally be more than one thread 
running at a time. To simulate the workload better we 
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Figure 11. Postmark execution times Figure 13 postmark Read Write throughput 
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Figure 12. Execution time for 10 Postmark 
processes 

ran 10 concurrent processes of Postmark, each with initial 
files of 2000 and 5000 transactions with the rest of the pa- 
rameters as in Table [6] The results for the time take to 
complete all the Postmark processes are shown in Figure 
[T2l The times for multiprocess Postmark are almost half 
that of a single process Postmark for the same parame- 
ters. We observer that standard TCP needs 17-50% more 
time than Fair-TCP to complete Postmark execution. The 
performance improvement observed going from a single 
Postmark process to multiple processes is due to several 
requests getting queued at the SCSI level. Fair-TCP has 
more data available at the TCP level in a multiprocess en- 
vironment than in a single process and this improves the 
performance. 

Figure[T4]shows the read and write throughput in a mul- 
tiprocess Postmark environment for standard TCP and Fair- 
TCP. The throughput shown are the aggregate throughput 



2 4 6 8 

Delay (ms) 

Figure 14. Aggregate Read and Write 
throughput for 10 Postmark processes 

for all the 10 processes. We see that Fair- TCP increases 
the aggregate read and write throughput by 17-50% over 
standard TCP. 

4.5. Kernel Compile 

The kernel compile experiment involves untar, config 
and make of 2.4.20 Linux kernel. The time taken in sec- 
onds to complete the kernel compile for various delays is 
shown in figure [15] Kernel compile is CPU intensive and 
generates large amounts of meta-data. Fair- TCP improves 
the performance of kernel compile by 8-17%. 

5. Related Work 

Due to increasing importance to storage scaling and re- 
ducing costs, there has been number of efforts to build ef- 



9 



ficient implementations of iSCSI and evaluate various as- 
pects ofiSCSI. 

The work in Aiken] 6] evaluates the performance of 
iSCSI in 3 different configurations, a commercial deploy- 
ment of iSCSI with Fibre Channel and iSCSI storage, a 
SAN environment with software-based targets and initia- 
tors using existing hardware and in a WAN emulated en- 
vironment with varying delays. The authors in [9 1 eval- 
uate the performance of iSCSI when used in storage out- 
sourcing. They examine the impact of latency on appli- 
cation performance and how caching can be used to hide 
network latencies. The authors in [ 1 1 1 use simulations to 
examine the impact of various iSCSI parameters such as 
iSCSI PDU size, Maximum Segment Size, Link Delay and 
TCP Window Size. The work in [ 12] examines the effect 
of block level request size and iSCSI window size in LAN, 
MAN and WAN environments. The work in flTOl exam- 
ines the use of various advanced TCP stacks such as FAST 
TCP, Binary Increase Congestion TCP (BIC-TCP), H-TCP, 
Scalable TCP and High-Speed TCP using simulations and 
a emulated wan. 

The authors in lfl6ll study the performance of iSCSI in 
the context of synchronous remote mirroring and find that 
iSCSI is a viable approach to cost-effective remote mirror- 
ing. The work in 1 7 1 compares the performance of NFS and 
iSCSI micro and macro benchmarks. The work in [ 13 1 ex- 
amines the impact of certain kernel SCSI subsystem values 
and suggest modifications to these value for performance 
improvement of iSCSI. [17] proposes a caching algorithm 
and localization of certain unnecessary protocol overheads 
and observe significant performance improvements over 
current iSCSI system. 

6. Conclusions 

In our work, we investigated the performance of iSCSI 
with multiple TCP connections and found that iSCSI 
throughput suffers from competing TCP connections. We 
proposed a TCB information sharing method called Fair- 
TCP based on the design of [20]. We implemented Fair- 
TCP for the Linux kernel and compared the performance 
of iSCSI with Fair-TCP and standard TCP under different 
workloads. We find that Fair-TCP improves the perfor- 
mance of iSCSI significantly in I/O intensive workloads. 
For workloads such as single threaded read, the SCSI data 
generated is quite low, hence Fair- TCP does do not as good 
as in I/O intensive workloads. 
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